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Diversion Indication in SIP 
Abstract 


This RFC, which contains the text of an Internet Draft that was 
submitted originally to the SIP Working Group, is being published now 
for the historical record and to provide a reference for later 
Informational RFCs. The original Abstract follows. 


This document proposes an extension to the Session Initiation 
Protocol (SIP). This extension provides the ability for the called 
SIP user agent to identify from whom the call was diverted and why 
the call was diverted. The extension defines a general header, 
Diversion, which conveys the diversion information from other SIP 
user agents and proxies to the called user agent. 


This extension allows enhanced support for various features, 
including Unified Messaging, Third-Party Voicemail, and Automatic 
Call Distribution (ACD). SIP user agents and SIP proxies that 
receive diversion information may use this as supplemental 
information for feature invocation decisions. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for the historical record. 


This document defines a Historic Document for the Internet community. 
This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5806. 
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IESG Note 


This document contains an early proposal to the IETF SIP Working 
Group that was not chosen for standardization. Discussions on the 
topic resulted in the informational RFC 3325, "Private Extensions to 
the Session Initiation Protocol (SIP) for Asserted Identity within 
Trusted Networks", and the standard solution that was chosen can be 
found in RFC 4244, "An Extension to the Session Initiation Protocol 
(SIP) for Request History Information". 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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Introduction 


This RFC, which contains the tezt of an Internet Draft that was 
submitted originally to the SIP Working Group, is being published now 
for the historical record and to provide a reference for later 
Informational RFCs. 


In the legacy telephony network, redirection information is passed 
through the network in ISDN/ISUP (ISDN User Part) signaling messages. 
This information is used by various service providers and business 
applications to support enhanced features for the end user. 


An analogous mechanism of providing redirection information would 
enable such enhanced features for SIP users. 


The Diversion header allows implementation of feature logic based on 
from whom the call was diverted. 


Terminology 
1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


.2. Definitions 


diversion: 
A change to the ultimate destination endpoint of a request. A 
change in the Request-URI of a request that was not caused by a 
routing decision. This is also sometimes called a deflection or 


redirection. 


A diversion can occur when the "user" portion of the Request-URI 
is changed for a reason other than expansion or translation. 


A diversion can occur when only the "host" portion of the Request- 
URI has changed if the change was due to a non-routing decision. 


divertor: 


The entity that diverted the call. 
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recursing: 


A SIP proxy or user agent that handles a received or internally 
generated 3xx response by forking new request(s) itself. 


non-recursing: 


A SIP proxy or user agent that handles a received or internally 
generated 3xx response by forwarding it upstream. 


2.3. Abbreviations 

CFUNC: Call Forward Unconditional 
CFTOD: Call Forward Time-of-Day 
CFB: Call Forward on Busy 


CFNA: Call Forward on No Answer 


CFUNV: Call Forward Unavailable 
ACD: Automatic Call Distribution 

3. Overview 
In order to implement certain third-party features such as Third- 
Party Voicemail and Automatic Call Distribution (ACD) applications, 
diversion information needs to be given to the called third party so 
that he may respond to the caller intelligently. In these 
Situations, the party receiving a diverted call needs answers for two 
questions: 
Question 1: From whom was the request diverted? 


Question 2: Why was the request diverted? 


This document proposes usage of the Diversion header to answer these 
questions for the party receiving the diverted call. 


Insertion of the previous Request-URI (before the diversion occurred) 
into the Diversion header answers question 1. 


Insertion of the "reason" tag into the Diversion header (by the 
divertor) answers question 2. 
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3.1. When Is the Diversion Header Used? 


The Diversion header SHOULD be added when a SIP proxy server, SIP 
redirect server, or SIP user agent changes the ultimate endpoint that 
will receive the call. 


Diversion information SHOULD NOT be added for normal call routing 
changes to the Request-URI. Thus, the Diversion header is not added 
when features such as speed dial change the Request-URI. 


When a diversion occurs, a Diversion header SHOULD be added to the 
forwarded request or forwarded 3xx response. The Diversion header 
MUST contain the Request-URI of the request prior to the diversion. 
The Diversion header SHOULD contain a reason that the diversion 
occurred. 


Existing Diversion headers received in an incoming request MUST NOT 
be removed or changed in forwarded requests. 


Existing Diversion headers received in an incoming response MUST NOT 
be removed or changed in the forwarded response. 


A Diversion header is added when features such as call forwarding or 
call deflection change the Request-URI. 


4. Extension Syntax 


The syntax of the Diversion header is: 


Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion params )) 
diversion-params - diversion-reason | diversion-counter | 
diversion-limit | diversion-privacy 
diversion-screen | diversion-extension 
diversion-reason = "reason" "=" 
( "unknown" | "user-busy" | "no-answer" | 
"unavailable" | "unconditional" | 
"time-of-day" | "do-not-disturb" | 
"deflection" | "follow-me" | 
"out-of-service" | "away" | 
token | quoted-string ) 
diversion-counter = "counter" "=" 1*2DIGIT 
diversion-limit = "limit" "=" 1*2DIGIT 
diversion-privacy = "privacy" "=" ( "full" | "name" | 
"uri" | "off" | token | quoted-string ) 
diversion-screen - "screen" "-" ( "yes" | "no" | token | 
quoted-string ) 
diversion-extension = token ["=" (token | quoted-string)] 
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The following is an extension of tables 4 and 5 in [RFC3261] for the 
Diversion header: 
where enc. e-e ACK BYE CAN INV OPT REG 


Diversion R h s - S lo) = - 
Diversion 3xx h = B ES lo) - - 


5. Detailed Semantics 
5.1. UAS Behavior 


A SIP User Agent Service (UAS) that receives a request and returns a 
3xx SHOULD add a Diversion header containing the previous Request-URI 
and the reason for the diversion. 


5.2. UAC Behavior 


A SIP UAC that receives a 3xx containing a Diversion header SHOULD 
copy the Diversion header into each downstream forked request that 
resulted from the 3xx. 


5.3. Redirect Server Behavior 


A SIP redirect server that receives a request and returns a 3xx 
containing a Contact that diverts the request to a different endpoint 
SHOULD add a Diversion header containing the Request-URI from the 
incoming request and the reason for the diversion. 


5.4. Proxy Server Behavior 


A non-recursing SIP proxy that receives a 3xx containing a Diversion 
header SHOULD forward the 3xx containing the Diversion header 
upstream unchanged. 


A SIP proxy that receives a request and invokes a feature that 
changes the Request-URI of the forwarded request in order to divert 
the request to a different endpoint SHOULD add a Diversion header 
containing the Request-URI from the incoming request and the reason 
for the diversion. 


A SIP proxy that receives a request and returns a 3xx containing a 
Contact that diverts the request to a different endpoint SHOULD add a 
Diversion header containing the Request-URI from the incoming request 
and the reason for the diversion. 
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5.4.1. Proxy Logic for Diversion Header 


if (pdu.is request()) { 
if (request-URI is changed due to a called feature) { 
if (proxy.is recursing()) { 
Add the Diversion header (indicating the reason 
that the call has been diverted) to 
the downstream forwarded request(s). 
) else { 
Add the Diversion header (indicating the reason 
that the call has been diverted) to 
the upstream forwarded 3xx response. 
} 
} 


) else if (pdu.is response()) { 
if (pdu.is 3xx()) | 
if (proxy.is recursing()) { 
Copy Diversion header into forwarded INVITE(s). 
) else { 


Forward response upstream. 


} 
} 
6. Examples Using Diversion Header 
There are several implementations of call forwarding features that 
can be implemented by either recursing or non-recursing SIP proxies 
or SIP user agents. 
A SIP proxy or user agent that generates or forwards 3xxs upstream is 
non-recursing. A SIP proxy or user agent that handles received (or 
internally generated) 3xxs itself is recursing. 
The following examples illustrate usage of the Diversion header for 
some of the variants of recursing and non-recursing proxies and user 
agents. 


6.1. Call Forward Unconditional 


Usage of the Diversion header is shown below for several variant 
implementations of Call Forward Unconditional. 


6.1.1. Network Call Forward Unconditional (P2 Recursing) 
In this message flow, the call would normally be routed to Bob@B. 


However, Proxy 2 (P2) recursively implements Call Forward 
Unconditional (CFUNC) to Carol8C. 
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4------------------------ + 
| Bob@P2: CFUNC->Carol@C | 
+------ +----------------- + 
\ 
\ 
A P1 P2 B 
recursing 


Diversion: Bob@P2 


| 

«-200--------- | 

| 

<-200--------- | | 

| | 
--ACK------------------------------------------------ 

| | 

| | 
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--INVITE Carol@C------- 


;reason-unconditiona 


C 


| 
| 
| 
| 
| 
1 
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6.1.2. Network Call Forward Unconditional 


Recursing) 


Diversion Indication in SIP 


March 2010 


(Pl Non-Recursing, P2 Non- 


In this message flow, Proxy 2 (P2) non-recursively implements Call 


Forward Unconditional (CFUNC) to Carol@C. Proxy 1 


recursing. 


A P1 


P2 B 


non-recursing  non-recursing 


--INV Bob@P1-> 


|--INV Bob@P2-> | 


Diversion: Bob@P2 
;reason-unconditional 


--INVITE CarolQ8C------------------------------------- 
Diversion: Bob@P2 


Contact: Carol@c 
Diversion: Bob@P2 


; reason=unconditional 


; reason=unconditional | | 
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| 
| 
| 
| 
| 
| 
| 
| 
| Contact: Carol@c 
| 
| 
| 
| 
| 
| 
| 


Historic 


(P1) 


is non- 
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6.1.3. Network Call Forward Unconditional 


Recursing) 


In this message flow, 
Forward Unconditional 


Proxy 2 
(CFUNC) 


(Pl Recursing, 


March 2010 


P2 Non- 


(P2) non-recursively implements Call 


to Carol@c. 


Proxy 1 


A Pl 


P2 B 


recursing non-recursing 


--INV Bob@P1-> | 
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| 
| 
| 
Contact: Carol@c | 
| 
| 


--INVITE Carol@c 
Diversion: Bob@P2 | 


--INV Bob@P2-> 


Diversion: Bob@P2 


; reason=unconditional 


; reason=unconditional | 


Historic 


(P1) 


is recursing. 
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6.1.4. Endpoint Call Forward Unconditional (P1 Recursing, P2 Non- 
Recursing) 
In this message flow, user agent server B (B) non-recursively 
implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 2 
(P2) is non-recursing. Proxy 1 (Pl) is recursing. 
R----------------------- t 
| Bob@B: CFUNC->Carol@c | 
+------ +---------------- + 
\ 
\ 
A P1 P2 B C 
recursing non-recursing 
| | | 
ima Bob@P1-> | 
| |--INV Bob@P2-> | | | 
| | |--INV Bob@B---> | | 
| | | | 
| | | <-302---------- | | 
Contact: CarolfC 
| | | Diversion: Bob@B | 
| | | ; reason-unconditional 
| | | | 
| | |--ACK--------- >| | 
| | | | | 
«-302--------- | 
Contact: Carol@C 
| | Diversion: Bob@B | | 
| | ; reason=unconditional | | 
| | | | 
| |--AcK-------- >| | | 
| WAA CarolgC------------------------ > 
| | Diversion: Bob@B | | 
| | ; reason=unconditional | | 
| | | | 
| |<-200------------------------------------ 
s=2:00-=====4== | 
| | | | | 
| --ACK-------------------------------------------------- > | 
| | | | | 
| | | | | 
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6.2. Call Forward on Busy 


Usage of the Diversion header is shown below for several variant 
implementations of Call Forward on Busy. 


6.2.1. Network Call Forward on Busy (P2 Recursing) 


In this message flow, Proxy 2 (P2) recursively implements Call 
Forward on Busy (CFB) to Carol@C. 


4---------------------- t 
| Bob@P2: CFB->Carol@c | 
+------ +--------------- + 
\ 
\ 
A P1 P2 B (e 
recursing 


| 
--INV Bob@P1->| | | 
| 
| 


--INV Bob@P2->| 


| 
| 
| 
| 
ET Bob@B-> | 
| 
| 
| 
| 


| 
|<-486-------- | 
| | 

| 
--INVITE Carol@C------- > 


| 

| 

| 

| 

| | --ACK------- > | 
| 

| ;reason-user-busy 
| 

| 


| Diversion: Bob@P2 
| 
| 
| 
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DUAE 


Recursing) 


In this message flow, 
(CFB) 


Forward on Busy 


P1 


non-recursing 


--INV Bob@P1->| 


Contact: Carol@c 
Diversion: Bob@P2 
;reason-user-busy 


Diversion: Bob@P2 
;reason-user-busy 
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--INV Bob@P2-> 


Contact: 
Diversion: 
;reason-user-busy 
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Network Call Forward on Busy 


Proxy 2 


P2 


|--INV Bob@B-> 


--INVITE CarolQC------------------------------------- 


to Carol@c. 


Carol@c 
Bob@P2 


(Pl Non-Recursing, 


(P2) 


Proxy 1 (Pl) 


non-recursing 


Historic 


March 2010 


P2 Non- 


non-recursively implements Call 
is non-recursing. 
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6.2.3. 


In this message flow, 
(CFB) 


Forward on Busy 


A Pl 
recursing 


Levy & Mohali 


Network Call Forward on Busy 


--INV Bob@P2-> 


| 

Contact: | 
Diversion: | 
;reason-user-busy | 
| 


--INVITE Carol@C 
Diversion: 
;reason-user-busy | 
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(P1 Recursing, 


Proxy 2 (P2) 


to Carol@C. Proxy 1 (P1) 


P2 B 
non-recursing 


|--INV Bob@B-> 


Carol@c 
Bob@P2 


Bob@P2 | 


Historic 


March 2010 


P2 Non-Recursing) 


non-recursively implements Call 


is recursing. 
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P2 Non-Recursing) 


In this message flow, user agent server B (B) non-recursively 
implements Call Forward on Busy (CFB) to Carol@C. Proxy 2 (P2) is 
non-recursing. Proxy 1 (P1) is recursing. 
4p--------------------- + 
| Bob@B: CFB-»CaroleC | 
+------ +-------------- + 
\ 
\ 
A PI P2 B C 
recursing non-recursing 
| | | | 
|--INV Bob@P1-> | | | | 
| mes Bob@P2-> | 
| | | | | 
| | |--INV Bob@B-> | | 
| | | | | 
| | |<-302-------- | | 
Contact: Carol@c 
| | | Diversion: Bob@B | 
| | | ;reason-user-busy | 
| | | | | 
| | |--ack---——-- d | 
| | | | | 
<=302========= 
| Contact: Carol@c | 
| | Diversion: Bob@B | | 
| | ;reason-user-busy | | 
| | | | 
| |--acx-------- d | | 
| cui Caro1@c---------------------- > 
| | Diversion: Bob@B | | 
| | ;reason-user-busy | | 
| | | | 
| |<-200---------------------------------- | 
s=2:00-=====4== | | 
| | | | | 
| --ACK------------------------------------------------ > | 
| | | | | 
| | | | | 
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6.3. Call Forward on No-Answer 


March 2010 


Usage of the Diversion header is shown below for several variant 
implementations of Call Forward on No-Answer. 


6.3.1. Network Call Forward on No-Answer (P2 Recursing) 


In this message flow, Proxy 2 (P2) recursively implements Call 


Forward on No Answer (CFNA) to Carol@C. 
AP AA A t 
| Bob@P2: CFNA->Carol@c | 
+------ +e SSeS SSSR Seas + 
\ 
\ 
A Pl P2 B e 
recursing 
| 
--INV Bob@P1-> | | | 
| | 
--INV Bob@P2->| | 
--INV Bob@B-> 
| | 
|<-180-------- | 
| | 
| | 
: | 
|--INVITE Carol@c------- > 


| 
| 
| 
| 
| 
| timeout 
| 
| 
| 
| 
| 


| Diversion: Bob@P2 
;reason-no-answer 


«-200------------------- 
| 
<-200--------- | | 
| | 
<-200--------- | | | 
| | | 
--ACK------------------------------------------------ > 
| | | 
| | | | 
Levy & Mohali Historic 
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623.23 
Recursing) 


In this message flow 


Forward on No Answer 
recursing. 


P1 
non-recursi 


--INV Bob@P1-> 


Conta 
Diver 


Contact: Carol@c 
Diversion: Bob@P2 
;reason=no-answer 


--INVITE CarolQC------------------------------------- > 


| 

| 

| 

| Diversion: Bob@P2 

| ;reason-no-answer 
| 

| 
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, Proxy 2 


(CENA) 


ng 


--INV Bob@P2->| 


|--INV Bob@B-> 


Network Call Forward on No-Answer 


(P2) 
to Carol@c. 


P2 
non-recursing 


timeout 


ct: 
sion: 


Carol@c 
Bob@P2 
;reason=no-answer 


Historic 


(P1 Non-Recursing, 


Proxy 1 (Pl) 


March 2010 


P2 Non- 


non-recursively implements Call 
is non- 
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6.3.3. Network Call Forward on No Answer (P1 Recursing, 
Recursing) 
In this message flow, Proxy 2 (P2) 
Forward on No Answer (CFNA) to Carol@C. Proxy 1 (P1) 
4----------------------- + 
| Bob@P2: CFNA->Carol@c | 
+------ +---------------- + 
\ 
\ 
A PI P2 B C 
recursing non-recursing 
| | | 
|--INV Bob@P1-> | | | | 
| --INV Bob@P2-> | | 
| | | | | 
| | |--INV Bob@B-> | | 
| | | | | 
| | B m | | 
| | | | | 
| | timeout | | 
| |<-302--------- | | | 
| | Contact: Carol@c | | 
Diversion: Bob@P2 
;reason-no-answer 
| | | | | 
| E oed | | 
| |--INVITE Carol@C---------------------- > | 
Diversion: Bob@P2 
;reason-no-answer 
| | | | 
| |<-200---------------------------------- | 
| | | | | 
|<-200--------- | | | | 
= ------------------------------------------------ > 
| 
| 
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non-recursively implements Call 


is recursing. 
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Recursing, B Non-Recursing) 


In this message flow, 
implements Call Forward on No Answer 
is non-recursing. Proxy 1 (P1) 


user agent server B 


P1 P2 


recursing 


--INV Bob@P1-> 


non-recursing 
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--INV Bob@B-> 


| 

| 

| ache fim ee ei 
| Contact: 

| Diversion: 

| 

| 


Contact: Carol@c 
Diversion: Bob@B 
;reason=no-answer 


Diversion: Bob@B 
;reason-no-answer 


Historic 


(CENA) 
is recursing. 


timeout 
Carol@c 


Bob@B 
;reason=no-answer 


--INVITE Carol@C---------------------- > 


(B) 
to Carol@c. 


March 2010 


P2 Non- 


non-recursively 


Proxy 2 (P2) 
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Usage of the Diversion header is shown below for several variant 


implementations of Call Forward on Unavailable. 


6.4.1. Network Call Forward on Unavailable 


(P2 Recursing) 


In this message flow, Proxy 2 (P2) recursively implements Call 
Forward on Unavailable (CFUNV) to Carol@C. 


A P1 


P2 B 
recursing 


|--INV Bob@P1-> | 


6.4.2. Network Call Forward on Unavailable 


Recursing) 
In this message flow, 


Forward on Unavailable 
recursing. 
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|--INV Bob@P2-> | 


timeout 


--INV Bob@B-> 
|--INV Bob@B-> | 
|--INV Bob@B-> | 


|--INV Bob@B-> | 


|--INVITE Carol@c------- > 
| Diversion: Bob@P2 | 
;reason-unavailable 


Historic 


(Pl Non-Recursing, 


P2 Non- 


Proxy 2 (P2) non-recursively implements Call 


(CFUNV) to Carol@C. Proxy 1 (P1) is non- 
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A P1 P2 
non-recursing non-recursing 


--INV Bob@P1-> 


|--INV Bob@P2-> | 


| 
| | edes 
| 
|<-100--------- 
--INV Bob@B-> 
--INV Bob@B-> 
| | |--INV Bob@B-> 
| | YA 
| | |--INV Bob@B-> 
| | timeout 
«-302--------- | 
Contact: Carol@c 
| Diversion: Bob@P2 
| ;reason-unavailable 
| 
| |--ACK-------- > 
«-302--------- 


Contact: Carol@c | 
Diversion: Bob@P2 
;reason-unavailable | 


--INVITE Carol@C------------------------------------- 


Diversion: Bob@P2 
;reason-unavailable | 
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6.4.3. Network Call Forward on Unavailable 


Recursing) 


In this message flow, 


Forward on Unavailable (CFUNV) to Carol@C. 
recursing. 
+ i i pi nm 
| Bob@P2: CFUNV->Carol@C | 
+------ p----------------- + 
\ 
\ 
A P1 P2 B 
recursing non-recursing 
| | 
--INV Bob@P1-> 
aa NA Wa 
| |--INV Bob@P2-> | | 
| |<-100--------- | 
| | |--INV Bob@B-> | 
| | |--INV Bob@B-> | 
| | --INV Bob@B-> 
| | |--INV Bob8B-»| 
| | timeout 
| |«-302--------- | | 
| | Contact: Carol@c 
Diversion: Bob@P2 
;reason-unavailable 
| | | | 
| | --ACK-------- > | | 
| | | | 
| |--INVITE CarolQC---------------------- 
Diversion: Bob@P2 
;reason-unavailable 
| | | 
| | <-200---------------------------------- 
| | | | 
| <-200--------- | | | 
| | | | 
--ACK------------------------------------------------ 
| 
| 


Levy & Mohali 


(P1 Recursing, 


P2 
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Proxy 2 (P2) non-recursively implements Call 


Historic 


Proxy 1 


(P1) 


is 
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6.5. Multiple Diversions 


Usage of the Diversion header when multiple diversions occur are 
shown the following two examples. 


6.5.1. Call Forward Unconditional and Call Forward Busy 


Proxy 2 (P2) implements Call Forward 


In this message flow, 
C then implements Call Forward on 


Unconditional (CFUNC) to Carol@c. 
Busy (CFB) to 5551234@D. P2 is non-recursing. Pl is recursing. C 
is non-recursing. 
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4R-----------2------------- * $------------------------- * 
| Bob@P2: CFUNC-»CaroleC | Carol@C: CFB->5551234@D | 
+--------------- +-------- + +-------- 4R---------------- * 

N N 
N N 

A Pl P2 B C D 

recursing non-recursing non-recursing 


--INV Bob@P1-> 


|--INV Bob@P2-> | 


Contact: Carol@c 
Diversion: Bob@P2 
;reason-unconditional 


| 
M 
| 
| | 
| | 
| | 
| | 
--INVITE Carol@c---------------------- > | | 
Diversion: Bob@P2 | | | 
| 
| 
| | 
| | 
| | 
| | 


;reason-unconditional | 


| 

| 

| 

| 

| 

| 

| Contact: 5551234@D 
| Diversion: Carol@c 
| 

| ;privacy="full" 
| 

| 

| 

| 

| 

| 

| 


Diversion: Bob@P2 


| 
| 
;reason-user-busy 
;reason-unconditional | 

| 


INVITE 5551234@D----------------------------—-- > 
Diversion: Carol@C | 
;reason-user-busy | 
iprivacy="full" | 
Diversion: Bob@P2 
;reason-unconditional 


«-200--------- | | | | 
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6.5.2. Call Forward Unconditional and Call Forward No Answer 


In this message flow, Proxy 2 (P2) implements Call Forward 
Unconditional (CFUNC) to Carol@c. (P2 would normally have routed the 
call to B). C then implements Call Forward on No Answer (CFNA) to 
5551234@D. P2 is recursing. C is recursing. 


4------------------------ To oR-------------------------- + 
| Bob@P2: CFUNC->Carolec | | carol@c: CFNA->5551234@D | 
+------------------ +----- + +----- +-------------------- + 

\ \ 
\ \ 

A P1 P2 B e D 

recursing recursing 


--INV Bob@P2->| | | 


--INV Bob@P1-> 


| 

| | 
| | 
| |--INV Carol@c->| | 
| | Diversion: Bob@P2 | 
| ;reason-unconditional | 
| | 
| | 
| | 
| 


[«--180--------- | 
| | | 
«-180--------- | | | 
| | | 
«-180--------- | | | | 
| | | | | 
| | | | timeout | 
| | | | |--INV 5551234@D-> | 
| | | | |Diversion: Carol@c 
;reason-no-answer 
;privacy="full" 
| | | | |Diversion: Bob@P2 
| | | | | ;reason- unconditional 
| | | | | 
| | | | |<-200----------—- | 
| | <=200.========22 | | 
| | | | | | | 
| [«-200--------- | | | | | 
| | | | | | | 
¡LI | | | | | | 
| | | | | | 
AC KO > 
| 
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7. 


8 


Security Considerations 


There are some privacy considerations when using the Diversion 
header. Usage of the Diversion header implies that the diverting UAS 
trusts the diverted-to UAS. Usage of the Diversion header by SIP 
proxies or SIP user agents can cause information leakage of route 
information and called information to untrusted SIP proxies and 
untrusted callers in upstream 3xxs.  Leakage of this information can 
be mitigated by having a recursing trusted upstream proxy server. 

For a SIP network architecture where all proxies are required to be 
non-recursive, Diversion header hiding may be considered necessary in 
order to prevent leakage of route information to the caller. To 
accomplish Diversion header hiding, a trusted upstream proxy would 
add a Record-Route header and use a secret key to encrypt the 
contents of the Diversion header in 3xxs that are forwarded upstream. 
On receipt of re-INVITEs, the proxy would decrypt the contents of the 
Diversion header (using its secret key) and forward the INVITE. 

There is no currently defined interaction of the Diversion and Hide 
headers. Question: Should there be? 


Further Examples 


Only the relevant headers have been included in the following 
examples. The contents of the Session Description Protocols (SDPs) 
have also been omitted. 


.l. Night Service/Automatic Call Distribution (ACD) Using Diversion 


Header 


In the following two message flows, two separate companies, 
WeSellPizza.com and WeSellFlowers.com, have contracted with a third 
company, NightService.com to provide nighttime support for their 
incoming voice calls. 


In the first flow, Alice calls out for pizza. In the second flow, 
Alice calls for roses. In both instances, the same night service 
company (and receptionist, Carol) answers the call. However, because 


the Diversion header is used, Carol is able to customize her greeting 
to the caller. 


Levy & Mohali Historic [Page 27] 


RFC 5806 Diversion Indication in SIP March 2010 


4------------------------------------- + 

WeSellPizza@P2: CFTOD->nightserv@P3 | 

+------------ 4------------------------ + 
\ 
\ 

UAC P1 P2 E3 UASI 
(WeSellPizza.com) (NightService.com) 
(ACD) 


[1] 
-INV pizza@P1-> 


[2] INVITE WeSellPizza@P2 


| 
| 
| [spas > | 
| | | 
[3] 
-INV nightserv@P3-> 
| | | Diversion: WeSellPizza@P2 
| | | ;reason-time-of-day 
| | | | 
| | | | t4] 
|-INV Carol@uas1--> 
Diversion: WeSellPizza@P2 
| | | ;reason-time-of-day | 
| | | | 
| | | |<-[5] 200--------- | 
| | |<-[6] 200---------- | | 
«-[7] 200----- 
«-[8] 200------ 
| | | | | 
lEsSl=AG&s=s==<5s=55==5#355=<=054335=445355 nas Sees >| 
| | | 
| 


|< "Hello, WeSellPizza"====== 


Alice calls for pizza. 
[1] SIP UAC to SIP proxy server 1: 


INVITE sip:pizza@pl.isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: sip:pizza@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 
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The ISP's originating proxy translated the keyword pizza to the 
company WeSellPizza.com 


[2] SIP proxy server 1 to SIP proxy server 2 (WeSellPizza.com): 


INVITE sip:WeSellPizza@p2.isp.com SIP/2.0 
Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:pizza@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Content-Type: application/sdp 


It's after midnight and the pizza people are in bed. Fortunately, 
WeSellPizza.com has contracted with NightService.com to answer their 
nighttime calls. Thus, P2 implements CFTOD to NightService.com. 


[3] SIP proxy server 2 (WeSellPizza.com) to 
SIP proxy server 3 (NightService.com): 


INVITE sip:NightService@p3.isp.com SIP/2.0 

Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:pizza@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:WeSellPizza@p2.isp.com> 
;reason-time-of-day 

Content-Type: application/sdp 


Carol is available to receive the incoming call. 
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[4] SIP proxy server 3 (NightService.com) to UAS1 (Carol): 


INVITE sip:carol@uasl.nightservice.com SIP/2.0 

Via: SIP/2.0/UDP p3.isp.com 

Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:pizza@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:WeSellPizza@p2.isp.com> 
;reason-time-of-day 

Content-Type: application/sdp 


The ACD keys off the Diversion header to pull up the WeSellPizza FAQ 
on Carol's web browser. 


[5] UAS1 to SIP proxy server 3: 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP p3.isp.com 

Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
Contact: carol@uasl.nightservice.com 
From: sip:alice@isp.com 

To: <sip:pizza@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


[6] SIP proxy server 3 to SIP proxy server 2: 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
Contact: carol@uasl.nightservice.com 
From: sip:alice@isp.com 

To: <sip:pizza@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeg: 1 INVITE 

Content-Type: application/sdp 
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[7] SIP proxy server 2 to SIP proxy server 1: 


SIP/2.0 200 OK 
Via: SIP/2.0/UDP pl.isp.com 


Via: SIP/2.0/UDP alice-pc.isp.com 


Contact: carol@uasl.nightservice.com 


From: sip:alice@isp.com 


To: <sip:pizza@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 


CSeq: 1 INVITE 
Content-Type: application/sdp 


[8] SIP proxy server 1 to UAC 


SIP/2.0 200 OK 


Via: SIP/2.0/UDP alice-pc.isp.com 


Contact: carol@uasl.nightservice.com 


From: sip:alice@isp.com 


To: <sip:pizza@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 


CSeq: 1 INVITE 
Content-Type: application/sdp 


[9] SIP UAC to UASI: 


ACK sip:uasl.nightservice.com SIP/2.0 


Via: SIP/2.0/UDP alice-pc.isp.com 


From: sip:alice@isp.com 


To: <sip:pizza@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 


CSeq: 1 INVITE 


The RTP flows begin and Carol answers 
help you?" 
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AA + 

WeSellFlowers@P4: CFTOD->nightserv@P3 | 

+------------- +------------------------- + 
\ 
\ 

UAC P1 PA P3 UAS1 
(WeSellFlowers.com) (NightService.com) 
(ACD) 


[1] 
-INV roses@P1-> 


Contact: nightservice@P3 
Diversion: WeSellFlowers@P4 
;reason-time-of-day 


| 

| 

| 

| 

| [5] 

-INVITE nightserviceQP3------------ > 
| Diversion: WeSellFlowers@P4 
| ;reason-time-of-day 

| 

| 

| 

| 


[6] 
| -INV Carol@uasl----- > 
| Diversion: WeSellFlowers@P4 


;reason-time-of-day 


«-[8] 200--------------------------- 
«-[9] 200------ 


-[10] ACK---------------------------------------------------------- >| 


| 
| 
|< "Hello, WeSellFlowers"-------| 
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Alice calls for roses. 


[1] 


SIP UAC to SIP proxy server 1: 


INVITE sip:roses@pl.isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: sip:roses@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


March 2010 


The ISP's originating proxy translated the keyword roses to the 
company WeSellFlowers.com 


[2] 


It's now 1 a.m. 


SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com): 


INVITE sip:WeSellFlowers@p4.isp.com SIP/2.0 


Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: sip:roses@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


and the florists are also in bed. 


Fortunately, 


WeSellFlowers.com has contracted with NightService.com to answer 
their nighttime calls, too. Thus, P4 implements CFTOD to 
NightService.com. 


[3] 


SIP proxy server 4 (WeSellFlowers.com) to 
SIP proxy server 1 (NightService.com): 


SIP/2.0 302 Moved Temporarily 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

Contact: NightService@p3.isp.com 

From: sip:alice@isp.com 

To: <sip:roses@pl.isp.com>;tag=p4 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:WeSellFlowers@p4.isp.com> 
;reason-time-of-day 
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[4] SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com): 
ACK sip:uasl.nightservice.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 
To: <sip:roses@pl.isp.com>;tag=p4 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 


[5] SIP proxy server 1 (WeSellFlowers.com) to 
SIP proxy server 3 (NightService.com): 


INVITE sip:NightService@p3.isp.com SIP/2.0 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:roses@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:WeSellFlowers@p4.isp.com> 
;reason-time-of-day 

Content-Type: application/sdp 


Carol is available to receive the incoming call. 
[6] SIP proxy server 3 (NightService.com) to UASI (Carol): 


INVITE sip:carol@uasl.nightservice.com SIP/2.0 

Via: SIP/2.0/UDP p3.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:roses@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:WeSellFlowers@p4.isp.com> 
;reason-time-of-day 

Content-Type: application/sdp 


The ACD keys off the Diversion header to pull up the WeSellFlowers 
FAQ on Carol's web browser. 
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[7] 


[8] 


[9] 


[10] 


The 


SIP UASI to SIP proxy server 3: 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP p3.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
Contact: carol@uasl.nightservice.com 
From: sip:alice@isp.com 

To: <sip:roses@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeg: 1 INVITE 

Content-Type: application/sdp 


SIP proxy server 3 to SIP proxy server 1: 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
Contact: carol@uasl.nightservice.com 
From: sip:alice@isp.com 

To: <sip:roses@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


SIP proxy server 1 to UAC 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP alice-pc.isp.com 
Contact: carol@uasl.nightservice.com 
From: sip:alice@isp.com 

To: <sip:roses@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


SIP UAC to SIP UASI: 


ACK sip:uasl.nightservice.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: <sip:roses@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 


RTP flows begin and Carol answers "Hello, 


I help you?" 
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WeSellFlowers. 
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How may 
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8.2. Voicemail Service Using Diversion Header 


Bob has contracted his Voicemail to a third-party company, 
Voicemail.com. In this message flow, Bob has hit the Do-Not-Disturb 
button on his phone. The Do-Not-Disturb functionality of Bob's phone 
is configured to CFUNC (Call Forward Unconditional) to 
voicemail@isp.com. Because the Diversion header is used, 
Voicemail.com is able to place the incoming call into Bob's voice 
mailbox. 
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HZ aa aaa aaa AA AOA * 
| Bob@UAS1: CFDoNotDisturb->voicemail@isp.com | 
Ka aaa _ ee | aaa aa aa 4------ * 
N 
\ 
UACI P1 P2 UASI UAS2 


Voicemail.com 


--[1] INV Bob@P1-> 


--[2] INV Bob@P2->| 


| | 

| | 

| [3] INV Bob@uas1->| 

| [4] «- 302------- | 

| Contact: voicemail@isp.com 
Diversion: Bob@uasl 

| ; reason=do-not-disturb 

| 

| 

| 


«-[6] 302--------- 
Contact: voicemail@isp.com 
| Diversion: BobQuasl 
| ; reason-do-not-disturb 
| 


<=:[/8:].:302====s==== 
Contact: voicemail@isp.com 


Diversion: Bob@uasl 
; reason-do-not-disturb 


| 
| 
| 
| 
--[7] ACK-------- >| 
| 
| 
| 
| 
| 


| 

| 

| 

| 

— INVITE. voLcemailldisp.com-=-=—-—=-==-=-----=- 222-3020002 > 
| Diversion: BobQuasl | | | 
| ; reason-do-not-disturb | | 

| | 
| 
| 


«--[11] 200---------------------------------------------------- | 
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Alice calls Bob. 
[1] SIP UAC to SIP proxy server 1: 


INVITE sip:Bob@pl.isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: sip:Bob@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


The ISP's originating proxy routes the request to proxy 2 


[2] SIP proxy server 1 to SIP proxy server 2: 


INVITE sip:Bob@p2.isp.com SIP/2.0 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

From: sip:alice@isp.com 

To: sip:Bob@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


[3] SIP proxy server 2 to UASI (Bob's SIP phone): 


INVITE sip:Bob@uasl.isp.com SIP/2.0 
Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: sip:Bob@pl.isp.com 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 


March 2010 


(P2). 


Since Bob had hit the Do-Not-Disturb button on his SIP phone, Bob's 


phone forwards the call to his voicemail service. 
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[4] User agent server 1 (UAS1) to SIP proxy server 2 (P2) 


SIP/2.0 302 Moved Temporarily 

Via: SIP/2.0/UDP p2.isp.com 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

Contact: Voicemail@isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:Bob@uasl.isp.com> 
; reason-do-not-disturb 


[5] SIP proxy server 2 to UASI (Bob's SIP phone): 


ACK sip:Bob@uasl.isp.com SIP/2.0 
Via: SIP/2.0/UDP p2.isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 


[6] SIP proxy server 2 (P2) to SIP proxy server 1 (P1): 


SIP/2.0 302 Moved Temporarily 

Via: SIP/2.0/UDP pl.isp.com 

Via: SIP/2.0/UDP alice-pc.isp.com 

Contact: Voicemail@isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:Bob@uasl.isp.com> 
; reason-do-not-disturb 


[7] SIP proxy server 1 to SIP proxy server 2: 


ACK sip:Bob@p2.isp.com SIP/2.0 
Via: SIP/2.0/UDP pl.isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 
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[8] SIP proxy server 1 (P1) to UAC (alice-po): 


SIP/2.0 302 Moved Temporarily 

Via: SIP/2.0/UDP alice-pc.isp.com 

Contact: Voicemail@isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 

Call-ID: 12345600@alice-pc.isp.com 

CSeq: 1 INVITE 

Diversion: <sip:Bob@uasl.isp.com> 
; reason-do-not-disturb 


[9] SIP UAC to SIP proxy server 1: 


ACK sip:Bob@pl.isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uasl 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 


[10] SIP UAC (alice-pc) to Voicemail server. 


INVITE sip:Voicemail@isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 
To: sip:Bob@pl.isp.com 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 
Diversion: <sip:Bob@uasl.isp.com> 

; reason-do-not-disturb 
Content-Type: application/sdp 


[11] Voicemail server to SIP UAC (alice-po): 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP alice-pc.isp.com 

Contact: Voicemail@isp.com 

From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uas2 

Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 

Content-Type: application/sdp 
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[12] SIP UAC to Voicemail server: 


ACK sip:Voicemail@isp.com SIP/2.0 
Via: SIP/2.0/UDP alice-pc.isp.com 
From: sip:alice@isp.com 

To: <sip:Bob@pl.isp.com>;tag=uas2 
Call-ID: 12345600@alice-pc.isp.com 
CSeq: 1 INVITE 


Because the Diversion header is present, the Voicemail server is able 
to place Alice’s message into Bob’s voice mailbox. 


dada 


Questions and Answers on Alternative Approaches 


Question 1: 


Why do we need the Diversion header when we can see the To: header? 


Answer: 


a) 


The To: header is not guaranteed to have significance to the 
called party. 


For example, the To: header may contain a locally significant URL 
(to the caller) such as a private numbering plan, speed dial 
digits, telephony escape digits, or telephony prefix digits. 


Without a Diversion header, enumerating all possible locally 
significant To: headers that anyone might use to contact 
Bob@uasl.isp.com becomes a configuration problem at 
Voicemail@isp.com and is prone to namespace collision. 


Support for Diversion headers enables Bob to contract a third- 
party service (Voicemail@isp.com) with a single globally 
significant URL for his voice mailbox (Bob@uasl.isp.com). 


Given a set of multiple diversions, there is a policy decision of 
which Diversion header takes precedence for service logic. 


Different services (or even different users for the same service) 
may want to configure this policy differently (first, last, second 
to last, ete). 
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Question 2: 


Why do we need the Diversion header when we can see the Via: header? 


Answer: 


The Via header does not contain information about servers whom have 
deflected the call (using a 3xx). 


9. Mapping ISUP/ISDN Redirection Information to SIP Diversion Header 


The discussions below regarding ISUP/ISDN reflect generic elements in 
ISUP/ISDN. In some variations of ISUP/ISDN, the information elements 
are represented differently. Regardless of the ISUP/ISDN variant, 
translation should be performed for the "first redirecting number" 
and the "last redirecting number". 


In order to prevent ambiguity, it is important to highlight a 
terminology mismatch between ISUP/ISDN and SIP. In SIP, a "redirect" 


indicates the act of returning a 3xx response. In ISUP/ISDN, a 
"redirection" is diversion of a call by a network entity. In 
ISUP/ISDN, a call may also be deflected (by an endpoint). Diversion 


is the more generic term that refers to either the act of an network 
redirection or endpoint deflection. 


In SIP, Diversion can be implemented as either an upstream 3xx (non- 
recursive) or an additionally forked downstream request (recursive). 
In the following text, a lowercase "redirect" indicates the SIP 
usage, while an uppercase "Redirect" indicates ISUP usage. 


9.1. Mapping ISUP/ISDN Diversion Reason Codes 
ISUP and ISDN define the following diversion reasons: 


0000 = Unknown 
0001 = Call forwarding busy or called DTE busy 
0010 = Call forwarding no reply 
1111 = Call forwarding unconditional or systematic 
call redirection 
1010 = Call deflection or call forwarding by the called DTE 
1001 = Call forwarding DTE out of order 
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Mapping of ISUP/ISDN reason codes to Diversion reason codes is 
performed as follows: 


ISUP/ISDN reason code Diversion reason code 
0001 "user-busy" 

0010 "no-answer" 

1111 "unconditional" 

1010 "deflection" 

1001 "unavailable" 

0000 all others 


9.2. Mapping ISUP Redirection Information to SIP Diversion Header 


This section describes how generic ISUP diversion information 
elements may be translated across an ISUP/SIP gateway. 


9.2.1.  ISUP Definitions 


Called Party Number The number of the party to which the 
call is currently being routed. 


Redirecting Number The number to which the call was being 
routed when the last diversion occurred. 


Redirecting Reason The reason that the last diversion 
occurred. 

Original Called Number The number to which the call was being 
routed when the first diversion 
occurred. 


Original Redirecting Reason The reason that the first diversion 
occurred. 


Redirection Counter The count of the total number of 
diversions that have occurred. 


Address Presentation Indication of whether presentation is 
allowed or restricted. 
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9.2.2.  ISUP Parameters 


When a SIP call transits a SIP/ISUP gateway, the following 
information in the ISUP message should be examined/set when 
translating SIP Diversion headers to ISUP diversion information: 


1) Redirecting Number 

2) Redirecting Reason 

3) Redirecting Address Presentation 
4) Original Called Number 

5) Original Redirecting Reason 

6) Original Address Presentation 

7) Redirection Counter 


An ISUP message contains information on the first and last diversions 
that occurred. The Redirection number is the number to which the 
call was being routed when the last diversion occurred. The 
Redirecting Reason is the reason that the last diversion occurred. 


The Original Called Number is the number to which the call was being 
routed when the first diversion occurred. The Original Redirecting 
Reason is the reason that the first diversion occurred. 


When only one Diversion has occurred, the number to which the call 
was being routed when the diversion occurred is in the Redirecting 
Number and the reason for that diversion is carried in the Redirect 
Reason. 


9.2.3. ISUP to SIP Translation 


The ISUP Redirecting Number SHOULD be used to set the value of the 
name-addr of the top-most Diversion header. The ISUP Redirecting 
Number address presentation SHOULD be used to set the value of the 
diversion-privacy of the top-most Diversion header. The ISUP 
Redirecting Reason SHOULD be used to set the value of the diversion- 
reason of the top-most Diversion header. When present, the Original 
Called Number SHOULD be used to set the name-addr of the bottom-most 
Diversion header. When present, the Original Redirecting Reason 
SHOULD be used to set the diversion-reason of the bottom-most 
Diversion header. When present, the Original Address Presentation 
SHOULD be used to set the diversion-privacy of the bottom-most 
Diversion header. 
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The Redirection Counter value minus 1 SHOULD be stored in the 
diversion- counter associated with the top-most Diversion header. 
Presence of the diversion-counter for the bottom-most Diversion 
header is optional. If present, the diversion-counter of the bottom- 
most Diversion header SHOULD be 1. 


9.2.4. SIP to ISUP Translation 


The name-addr of the top-most Diversion header SHOULD be used to set 
the ISUP Redirecting Number. The diversion-reason of the top-most 
Diversion header SHOULD be used to set the ISUP Redirecting Reason. 
The diversion-privacy of the top-most Diversion header SHOULD be used 
to set the ISUP Redirecting Address Presentation. 


When multiple Diversion headers are present, the name-addr of the 
bottom- most Diversion header SHOULD be used to set the ISUP Original 
Redirecting Number. When multiple Diversion headers are present, the 
diversion-reason of the bottom-most Diversion header SHOULD be used 
to set the ISUP Original Redirecting Reason. When multiple Diversion 
headers are present, the diversion-privacy of the bottom-most 
Diversion header SHOULD be used to set the ISUP Original Redirecting 
Address Presentation. 


The ISUP Redirection Counter SHOULD be set equal to the sum of the 
counters of all Diversion headers in the SIP message. A Diversion 
header that does not explicitly specify a diversion-counter tag 
counts as 1. 
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9.2.5. Example of ISUP to SIP Translation 


Called Party Number 

Redirecting Number 
Address Presentation 

Original Called Number 


RedirectionInformation: 


Original Redirecting 
Redirecting Reason - 
Redirection Counter 


Levy & Mohali 


ISUP/SIP GW 


=+19195551004 
=+19195551002 
=presentation 
=+19195551001 


estricted 


Reason = Unconditional (1111) 


User busy (0001) 


5 


Historic 


--INVITE 419195551004------ » 


Diversion: <tel:+19195551002> 
;reason-user-busy 
;privacy="full" 

; counter=4 

Diversion: <tel:+19195551001> 
; reason=unconditional 
; counter=1 
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9.2.6. Example of SIP to ISUP Translation 
ISUP/SIP GW 


|<--INVITE +19195551004------ 
| Diversion: <tel:+19195551002> 
| ;reason-user-busy 
| iprivacy="full" 

; counter-4 
| Diversion: <tel:+19195551001> 
| ; reason=unconditional 
| ; counter=1 
| 
| 


«--IAM--------------------------------- 
Called Party Number =+19195551004 
Redirecting Number =+19195551002 | 


Address Presentation =presentation restricted 
Original Called Number =+19195551001 | 
RedirectionInformation: 

Original Redirecting Reason = Unconditional (1111) 

Redirecting Reason = User busy (0001) 

Redirection Counter = 5 


9.3. Mapping ISDN Redirection Information to SIP Diversion Header 


An ISDN message can contain up to two instances of a Redirecting 
Number information element. When a diversion occurs, an additional 
Redirection number information element is added. When a third (or 
greater) diversion occurs, the new Redirecting Number information 
element replaces the bottom-most Redirection number information 
element. 


9.3.1. ISDN Definitions 


Called Party Number The number of the party to which the 
call is currently being routed. 


Redirecting Number 

information element Aggregate information element that 
contains Redirecting number and Reason 
for diversion. 
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9. 


3 


Redirecting Number The number to which the call was being 
routed when the last diversion occurred. 


Reason for Diversion The reason that the last diversion 
occurred. 

Origin of Number Indicates whether the number is user 
provided and screened or network 
provided. 

Presentation Status Indicates if presentation is allowed or 
prohibited. 

.2. ISDN Parameters 


When a SIP call transits a SIP/ISDN gateway, the following 
information in the ISDN message should be examined/set when 
translating SIP Diversion headers to ISDN diversion information: 


1) Redirecting Number of the top-most Redirecting Number 
information element 


2) Reason for diversion of the top-most Redirection number 
information element 


3) Origin of Number and Presentation Status of the top-most 
Redirection number information element 


4) Redirection number of the bottom-most Redirection number 
information element 


5) Reason for diversion of the bottom-most Redirection number 
information element 


6) Origin of Number and Presentation Status of the bottom-most 
Redirection number information element 


An ISDN message contains information on the first and last diversions 
that occurred. The top-most Redirection number information element 
contains information (including the Redirecting Number, Origin of 
Number, Presentation Status, and Reason for diversion) about the last 
diversion that occurred. The bottom-most Redirection number 
information element contains information (including the Redirecting 
Number, Origin of Number, Presentation Status, and Reason for 
diversion) about the first diversion that occurred. 


If only one Diversion has occurred, only one Redirection number 
information element is present. 
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The Redirecting Number information element has the same Type of 
Number/Numbering Plan, and Digits as the Calling Party Number 
information element. 


There is no Redirection Counter associated with this ISDN information 
element. 


Notice that the order of the Redirection number information elements 
in an ISDN message (top-first, bottom-last) is reversed from the 
order of Diversion headers in a SIP message (top-last, bottom-first). 


9.3.3. ISDN to SIP Translation 


The Redirecting Number of the top-most ISDN Redirecting Number 
information element SHOULD be used to set the value of the name-addr 
of the bottom-most Diversion header. The Reason for Diversion of the 
top-most ISDN Redirecting Number information element SHOULD be used 
to set the value of the diversion-reason of the bottom-most Diversion 
header. 


The Origin of Number of the top-most ISDN Redirecting Number 
information element SHOULD be used to set the value of the diversion- 
Screen of the bottom-most Diversion header. The Presentation Status 
of the top-most ISDN Redirecting Number information element SHOULD be 
used to set the value of the diversion-privacy of the bottom-most 
Diversion header. 


The Redirecting Number of the bottom-most ISDN Redirecting Number 
information element SHOULD be used to set the value of the name-addr 
of the top-most Diversion header. The Reason for Diversion of the 
bottom-most ISDN Redirecting Number information element SHOULD be 
used to set the value of the diversion-reason of the top-most 
Diversion header. 


The Origin of Number of the bottom-most ISDN Redirecting Number 
information element SHOULD be used to set the value of the diversion- 
Screen of the top-most Diversion header. The Presentation Status of 
the bottom-most ISDN Redirecting Number information element SHOULD be 
used to set the value of the diversion-privacy of the top-most 
Diversion header. 


Presence of the diversion-counter in each of the Diversion headers is 


optional. If present, the diversion-counter of each Diversion header 
SHOULD be 1. 
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9.3.4. SIP to ISDN Translation 


The name-addr of the top-most Diversion header SHOULD be used to set 
the Redirecting Number of the bottom-most ISDN Redirecting Number 
information element. 


The diversion-reason of the top-most Diversion header SHOULD be used 
to set the Reason for Diversion of the bottom-most ISDN Redirecting 
Number information element. 


The diversion-screen of the top-most Diversion header SHOULD be used 
to set the Origin of Number of the bottom-most ISDN Redirecting 
Number information element. 


The diversion-privacy of the top-most Diversion header SHOULD be used 
to set the Presentation Status of the bottom-most ISDN Redirecting 
Number information element. 


The name-addr of the bottom-most Diversion header SHOULD be used to 
set the Redirecting Number of the top-most ISDN Redirecting Number 
information element. 


The diversion-reason of the bottom-most Diversion header SHOULD be 
used to set the Reason for Diversion of the top-most ISDN Redirecting 
Number information element. 


The diversion-screen of the bottom-most Diversion header SHOULD be 
used to set the Origin of Number of the top-most ISDN Redirecting 
Number information element. 


The diversion-privacy of the bottom-most Diversion header SHOULD be 


used to set the Presentation Status of the top-most ISDN Redirecting 
Number information element. 


Levy & Mohali Historic [Page 50] 


RFC 5806 Diversion Indication in SIP 


9.3.5. Example of ISDN to SIP Translation 


ISDN/SIP GW 


==SetUp====>=2=== 23535 232329323 =2S= > 
Called party number =+19195551004 
Redirecting Number information element: 
Redirecting Number =+19195551001 


Reason for redirection = Unconditional (1111) 
Origin of Number passed network screening 


Presentation Status = presentation allowed 
Redirecting Number information element: 
Redirecting Number =+19195551002 
Reason for redirection = User busy (0001) 
Origin of Number = passed network screening 
Presentation Status = presentation prohibited 
|--INVITE tel: 
| Diversion: 
| ;reason-u 
| ;screen=" 
¡privacy= 
Diversion: 
;reason-u 
;screen=" 
;privacy= 
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+19195551004----> 
<tel:+19195551002> 
ser-busy 

yes" 

"off" 
<tel:+19195551001> 
nconditional 

yes" 

" full" 
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9.3.6. Example of SIP to ISDN Translation 


ISDN/SIP GW 


<==Setup=========s=s=====s===-escsssees | 
Called party number =+19195551004 
Redirecting Number information element: 
Redirecting Number =+19195551001 


Reason for redirection = Unconditional (1111) 
Origin of Number passed network screening 


Presentation Status = presentation allowed 
Redirecting Number information element: 

Redirecting Number =+19195551002 

Reason for redirection = User busy (0001) 

Origin of Number = passed network screening 

Presentation Status = presentation prohibited 


|<--INVITE tel:+19195551004---- 
| Diversion: <tel:+19195551002> 
| ;reason-user-busy 
| ¡screen="yes" 
;privacy="off 

Diversion: <tel:+19195551001> 
| ; reason=unconditional 
| ¡screen="yes" 
| iprivacy="full" 
| 


9.4. Information Loss in SIP to ISUP/ISDN Translation 
Because ISUP and ISDN only support a subset of the information in a 
SIP Diversion header, information loss occurs during translation at a 
SIP/ISUP or SIP/ISDN boundary. 

9.4.1. Loss of Diversion URI Information 
Because ISUP and ISDN only support a subset of URI types 
(specifically tel: URIs and sip:x@y;user=phone URIs), diversion 
information occurring for other URI types may be lost when crossing 
from SIP to ISDN or ISUP. 

9.4.2. Loss of Diversion Reason Information 
Because ISUP and ISDN only support a subset of the reason codes 


supported by the Diversion header, specific reason code information 
may be lost when crossing from SIP to ISDN or ISUP. 
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9.4.3. Loss of Diversion Counter Information 


Because ISDN does not support a counter field (indicating the number 
of diversions that have occurred), counter information may be lost 
when crossing from SIP to ISDN. 
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